Software programming has evolved over time from writing applications in low-level languages, such as assembly, to high-level languages like C++, C#, and Visual Basic. Higher-level languages often remove low-level management of memory and other machine-based limitations in favor of allowing the programmer to think more in terms of objects that represent the problem to be solved. However, there is still much complexity in application logic, particularly when managing asynchronous processing. Workflows, such as those provided by MICROSOFT™ WINDOWS™ Workflow Foundation (WF), provide a declarative framework for formulating application and service logic in a high-level manner as one or more workflows. Workflows are made of activities that process a particular step of the application's processing. A group of activities forms a workflow. Workflows can be paused and resumed as applications wait for responses from other components, and are particularly well suited to asynchronous programming and improves developer productivity. WF provides a set of tools for declaring workflows, activities to help define the logic and control flow, and a runtime for executing the resulting application definition.
Workflows are hosted in a workflow host, which provides the runtime logic for reading and processing the activities of the workflow. In MICROSOFT™ .NET 4.0, WF introduced the ability to include messaging activities in a workflow and to host messaging-based workflows as a MICROSOFT™ WINDOWS™ Communication Foundation (WCF) service. This allows developers to quickly write applications that send and receive messages and act as a service. Messaging activities make it easy for developers to send, receive, and reply to messages between applications or application components.
Workflows may exercise or demand certain capabilities that are offered only by certain types of hosts. For example, a workflow that wants to receive messages (using messaging activities) needs a host that has messaging capabilities or a ‘messaging host’. Messaging is the primary means of activating/creating workflow instances and data exchange with workflows in a messaging host. On the other hand, non-messaging workflowscan be hosted by a non-messaging host that provides alternate means to create instances of such workflows and exchange data with them. A developer may not intend to lock himself into one type of workflow (messaging vs. non-messaging) when writing an application, and may want to define a set of workflows that can be run in the same host and interact with them in a consistent fashion. Today, the developer's only choice is to use different hosts for messaging and non-messaging workflows and interact with them differently.